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© Method and apparatus enabling software trial with computer-dependent identification. 



© A method and apparatus is provided for distrib- 
uting a software object from a source to a user. A 
software object is encrypted with an encryption op- 
eration utilizing a long-lived encryption key. It is 
directed from the source to the user. It is loaded 
onto a user-controlled data processing system hav- 
ing a particular configuration. A numerical machine 
identification is derived based at least in part upon 
the particular data processing system configuration 
of the user-controlled data processing system. A 
temporary key is derived which is based at least in 
part upon the numerical machine identification and 
the long-lived encryption key. The long-lived key 
generator is provided for receiving the temporary 
key and producing the long-lived encryption key. 
The user is allowed to utilize the temporary key for a 
prescribed interval to generate the long-lived encryp- 



tion key to access the software object. 
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CROSS-REFERENCE TO RELATED APPLICA- 
TION 

The present application is related to U.S. Pat- 
ent Application Serial No. 08/235,033, entitled 
"Method and Apparatus for Enabling Trial Period 
Use of Software Products: Method and Apparatus 
for Utilizing a Decryption Stub," further identified 
by Attorney Docket No. BT9-93-070; U.S. Patent 
Application Serial No. , entitled "Method and Ap- 
paratus for Enabling Trial Period Use of Software 
Products: Method and Apparatus for Allowing a 
Try-and-Buy User Interaction further identified by 
Attorney Docket No. DA9-94-008; U.S. Patent Ap- 
plication Serial No. 08/235,031, entitled "Method 
and Apparatus for Enabling Trial Period Use of 
Software Products: Method and Apparatus for Uti- 
lizing an Encryption Header," further identified by 
Attorney Docket No. DA9-94-010; and U.S. Patent 
Application Serial No. 08/238,41 8, entitled "Method 
and Apparatus for Enabling Trial Period Use of 
Software Products: Method and Apparatus for Al- 
lowing the Distribution of Software Objects," and 
further identified by Attorney Docket No. DA 994 
011. all filed of even date herewith by the inventors 
hereof and assigned to the assignee herein, and 
incorporated by. reference-herein - 

BACKGROUND OF THE INVENTION 

Sfc 1 . Technical Field: 

The present invention relates in general to 
techniques for securing access to software objects, 
and in particular to techniques for temporarily en- 
crypting and restricting access to software objects. 

2. Description of the Related Art: 

The creation and sale of software products has 
created tremendous wealth for companies having 
innovative products, and this trend will continue 
particularly since consumers are becoming ever- 
more computer literate as time goes on. Computer 
software is difficult to market since the potential 
user has little opportunity to browse the various 
products that are available. Typically, the products 
are contained in boxes which are shrink-wrapped 
closed, and the potential customer has little or no 
opportunity to actually interact with or experience 
the software prior to purchasing. This causes con- 
siderable consumer dissatisfaction with products, 
since the consumer is frequently forced to serially 
purchase a plurality of software products until an 
acceptable product is discovered. This is perhaps 
one significant cause of the great amount of soft- 
ware piracy which occurs in our economy. A poten- 
tial software purchaser will frequently "borrow" a 
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set of diskettes from a friend or business associate, 
with the stated intention of using the software for a 
temporary period. Frequently, such temporary use 
extends for long intervals and the potential cus- 
5 tomer may never actually purchase a copy of the 
software product, and may instead rely upon the 
borrowed copy. 

Since no common communication channel ex- 
ists for the sampling of software products, such as 
10 those created in movie theaters by movie trailers, 
and in television by commercials, software manu- 
facturers are forced to rely upon printed publica- 
tions and direct mail advertisements in order to 
advertise new products and solicit new customers. 
75 Unfortunately, printed publications frequently fail to 
provide an accurate description of the product, 
since the user interaction with the product cannot 
be simulated in a static printed format. The manu- 
facturers of computer software products and the 
20 customers would both be well served if the cus- 
tomers could have access to the products prior to 
making decisions on whether or not to purchase 
the product, if this could be accomplished without 
introducing risk of unlawful utilization of the prod- 
25 uct. 

The distribution of encrypted software products 
is_.one_.mechanism „a software vendor c 

distribute the product to potential users prior to 
purchase; however, a key must be distributed 

30 which allows the user access to the product. The 
vendor is then forced to rely entirely upon the 
honesty and integrity of a potential customer. Un- 
scrupulous or dishonest individuals may pass keys 
to their friends and business associates to allow 

35 unauthorized access. It is also possible that unscru- 
pulous individuals may post keys to publicly-acces- 
sible bulletin boards to allow great numbers of 
individuals to become unauthorized users. Typi- 
cally, these types of breaches in security cannot be 

40 easily prevented, so vendors have been hesitant to 
distribute software for preview by potential cus- 
tomers. 

SUMMARY OF THE INVENTION 

45 

It is one object of the present invention to 
provide a method and apparatus for distributing 
software objects from a producer to potential users 
which allows the user a temporary trial period with- 

50 out subjecting the software product to unnecessary 
risks of piracy or unauthorized utilization beyond 
the trial interval. Preferably this is accomplished by 
providing a software object on a computer-acces- 
sible memory media along with a file management 

55 program. Preferably, the software object is revers- 
ibly functionally limited, through one or more par- 
ticular encryption operations. The computer-acces- 
sible memory media is shipped from the producer 
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to the potential user utilizing conventional mail and 
delivery services. Upon receipt, the potential user 
loads the file management program into a user- 
controlled data processing system and associates 
it with the operating system for the data processing 
system. Then, the computer-accessible memory 
media is read utilizing the user-controlled data pro- 
cessing system. The file management program is 
executed by the user-controlled data processing 
system and serves to restrict access to the soft- 
ware object for a predefined and temporary trial 
period. During the temporary trial mode of opera- 
tion, the software object is temporarily enabled by 
reversing the reversible functional limitation of the 
software object. This is preferably accomplished by 
decryption of the encrypted software object when 
the software object is called by the operating sys- 
tem of the user-controlled data processing system. 
The file management program preferably prevents 
copying operations, so the encrypted software ob- 
ject is temporarily decrypted when it is called by 
the operating system. If the potential user elects to 
purchase the software object, a permanent use 
mode of operation is entered, wherein the func- 
tional limitation of the software object is perma- 
nently reversed, allowing unlimited use to the soft- 
ware object by the potential user. This facilitates 
browsing operations which allow the potential user 
to review the software and determine whether it 
suits his or her needs. 

The file management program continuously 
monitors the operating system of the user-con- 
trolled data processing system for operating sys- 
tem input calls and output calls. The file manage- 
ment program identifies when the operating system 
of the user-controlled data processing system calls 
for a software object which is subject to trial- 
interval browsing. Then, the file management sys- 
tem fetches a temporary access key associated 
with the software object, and then examines the 
temporary access key to determine if it is valid. 
Next, the file management program reverses the 
functional limitation of the software object, and 
passes it to the data processing system for pro- 
cessing. 

It is another objective of the present invention 
to provide a method and apparatus for distributing 
a software object from a source to a user, wherein 
a software object is encrypted utilizing a long-lived 
encryption key, and directed from the source to the 
user. The encrypted software object is loaded onto 
a user-controlled data processing system having a 
particular system configuration. A numerical ma- 
chine identification based at least in part upon the 
particular configuration of the user-controlled data 
processing system is then derived. Next, a tem- 
porary key is derived which is based at least in 
part upon the numerical machine identification and 
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the long-lived encryption key. A long-lived key gen- 
erator is provided for receiving the temporary key 
and producing the long-lived encryption key. The 
temporary key allows the user to generate for a 
5 prescribed interval the long-lived encryption key to 
access the software object. These operations are 
performed principally by a file management pro- 
gram which is operable in a plurality of modes. 
These modes include a set up mode of operation, 
io a machine identification mode of operation, and a 
temporary key derivation mode of operation. During 
the set up mode of operation, the file management 
program is loaded onto a user-controlled data pro- 
cessing system and associated with an operating 
75 system for the user-controlled data processing sys- 
tem. During the machine identification mode of 
operation, the file management program is utilized 
to derive a numerical machine identification based 
upon at least on attribute of the user-controlled 
20 data processing system. During the temporary key 
derivation mode of operation, a temporary key is 
derived which is based at least in part upon the 
numerical machine identification. The file manage- 
ment program also allows a trial mode of operation, 
25 wherein the file management program is utilized by 
executing it with the user-controlled data process- 
ing system to restrict access to the software object 
for an interval defined by the temporary key, during 
which the long-lived key generator is utilized in the 
30 user-controlled data processing system to provide 
the long-lived key in response to receipt of at least 
one input including the temporary key. 

It is yet another objective of the present inven- 
tion to provide a method and apparatus in a data 
35 processing system for securing access to particular 
files which are stored in a computer-accessible 
memory media. A file management program is 
provided as an operating system component of the 
data processing system. A plurality of files are 
40 stored in the computer-accessible memory media, 
including at least one encrypted file and at least 
one unencrypted file. For each encrypted file, a 
preselected portion is recorded in computer mem- 
ory, a decryption block is generated which includes 
45 information which can be utilized to decrypt the 
file, and the decryption block is incorporated into 
the file in lieu of the preselected portion which has 
been recorded elsewhere in computer memory. 
The file management program is utilized to monitor 
so data processing operation calls for a called file 
stored in the computer-accessible memory media. 
The file management program determines whether 
the called file has an associated decryption block. 
The file management program processes the called 
55 file in a particular manner dependent upon whether 
or not the called file has an associated decryption 
block. The incorporation of the decryption block 
does not change the size of the encrypted file, thus 

3 
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preventing certain types of processing errors. Dur- 
ing the trial interval, the encrypted file is main- 
tained in an encrypted condition, and cannot be 
copied. If the potential user opts to purchase the 
software product, a permanent key is provided 
which results in replacement of the preselected 
portion to the file in lieu of the decryption block 
Once the decryption block is removed, the encryp- 
ted file may be decrypted to allow unrestricted use 
by the purchaser. Preferably, the file management 
program is utilized to intercept files as they are 
called by the operating system, and to utilize the 
decryption block to derive a name for a key file 
and read the called file. The decryption block of 
each encrypted file includes a validation segment 
which is decrypted by the file management pro- 
gram and compared to a selected segment for the 
called file to determine whether the key can de- 
crypt the particular file. If the decrypted validation 
segment matches a known clear text validation 
segment, the file is then dynamically decrypted as 
it is passed for further processing. 

It is yet another objective of the present inven- 
tion to provide a method and apparatus in a data 
processing system for securing access to particular 
files which are stored in a computer-accessible 
memory media. A file management program is 
provided as an operating system component of a 
data processing system. In a computer-accessible 
memory media available to the data processing 
system, at least one encrypted file and one unen- 
crypted file are stored. The encrypted file has 
associated with it an unencrypted security stub 
wh is at least partially composed of executable 
co The file management program is utilized to 
nv m" the data processing system calls for a 
cam.-. J file stored in the computer accessible mem- 
ory media, to determine whether the called file has 
an associated unencrypted security stub, and to 
process the called file in a particular manner de- 
pendent upon whether or not the called file has an 
associated unencrypted security stub. More par- 
ticularly, if it is determined that the called file has 
no associated unencrypted security stub, the called 
file is allowed to be processed. However, if it is 
determined that the called file has an associated 
unencrypted security stub, it must be examined 
before a decision can be made about whether or 
not to allow it to be processed. First, the unencryp- 
ted security stub is examined in order to obtain 
information which allows decryption operations to 
be performed. Then, the decryption operations are 
performed. Finally, the called file is allowed to pass 
for further processing. Preferably, the called file is 
dynamically decrypted as it is passed to the op- 
erating system for processing. Also, the unencryp- 
ted security stub is separated from the called file 
prior to execution of the called file. However, if the 



unencrypted security stub accidentally remains at- 
tached to the called file, processing operations 
must be stopped, and a message must be posted 
in order to prevent the processor from becoming 
5 locked-up. 

It is still another objective of the present inven- 
tion to provide a method and apparatus for distrib- 
uting a software object from a source to a user. A 
computer-accessible memory media is distributed 
io from the source to a potential user. It includes a 
software object which is encrypted utilizing a pre- 
. determined encryption engine and a long-lived and 
secret key. An interface program is provided which 
facilitates interaction between the source and the 
is user. The interface program includes machine 
identification module which generates a machine 
identification utilizing at least on predetermined at- 
tribute of the user-controlled data processing sys- 
tem. It also further includes a long-lived and secret 
20 key generator which receives as an input at least a 
temporary key and produces as an output a long- 
lived and secret key. A validation module is pro- 
vided which tests temporary key determined its 
validity. The source of the software object main- 
25 tains a temporary key generator which receives as 
an input at least a machine identification and pro- 
duces an output of the temporary key. An interface 
program is loaded onto the user-controlled data 
processing system. The machine identification 
30 module is utilized to examine at least one predeter- 
mined attribute of the user-controlled data process- 
ing system and to generate the machine identifica- 
tion. During interaction between the source and the 
user, the machine identification is communicated 
35 over an insecure communication channel. At the 
source of the software object, the temporary key is 
generated utilizing the machine identification (and 
other information) as an input to the temporary key 
generator. During interaction between the source 
40 and the user, the temporary key is communicated, 
typically over an insecure communication channel. 
Nest, the validation module is utilized to determine 
the validity of the temporary key. The long-lived 
and secret key generator is then utilized to receive 
45 the temporary key and generate the long-lived and 
secret key in order to decrypt and temporarily gain 
access to the software object. The user is also 
provided with an import module and an export 
module which allow for the utilization of portable 
so memory media to transfer the encrypted software 
object, a key file, and a machine identification file 
from one machine in a distributed data processing 
system to another machine in the distributed data 
processing system, while allowing the temporary 
55 key to allow temporary trial access to the software 
object. 

The above as well as additional objectives, 
features, and advantages of the present invention 
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will become apparent in the following detailed writ- 
ten description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 

The novel features believed characteristic of 
the invention are set forth in the appended claims. 
The invention itself, however, as well as a preferred 
mode of use, further objectives and advantages 
thereof, will best be understood by reference to the io 
following detailed description of an illustrative em- 
bodiment when read in conjunction with the accom- 
panying drawings, wherein: 

Figure 1 is a pictorial representation of a stand- 
alone data processing system, a telephone, and 15 
a variety of computer-accessible memory media 
all of which may be utilized in the implementa- 
tion of the preferred technique of enabling trial 
period use of software products; 

Figure 2 is a pictorial representation of a distrib- 20 
uted data processing system which may utilize 
the technique of the present invention of en- 
abling trial period use of software products; 
Figure 3 is a block diagram representation of 
data processing system attributes which may be 25 
utilized to generate a machine identification, in 
accordance with the present invention; 
Figure 4 is a block diagram depiction of a 
routine for encrypting software objects; 
Figure 5 is a pictorial representation of the 30 
exchange of information between a source (a 
software vendor) and a user (a customer), in 
accordance with the teachings of the present 
invention; 

Figure 6 is a flowchart representation of the 35 
broad steps employed in building a user inter- 
face shell, in accordance with the present inven- 
tion; 

Figure 7 is a flowchart representation of vendor 

and customer interaction in accordance with the 40 

present invention; 

Figures 8, 9, 10a, and 10b depict user interface 

screens which facilitate trial period operations in 

accordance with the present invention; 

Figure 11 depicts a user interface which is used 45 

to initiate a temporary access key; 

Figure 12 is a block diagram depiction of the 

preferred technique of generating a machine 

identification; 

Figure 13 is a block diagram depiction of an 50 
encryption operation which is utilized to encrypt 
a machine identification, in accordance with the 
present invention; 

Figure 14 is a block diagram representation of 
the preferred technique for generating a product 55 
key, in accordance with the present invention; 
Figure 15 is a block diagram representation of a 
preferred technique utilizing a temporary prod- 



uct key to generate a real key which can be 
utilized to decrypt one or more software objects; 
Figures 16 and 17 depict a preferred technique 
of validating the real key which is derived in 
accordance with the block diagram of Figure 
15; 

Figure 18 is a block diagram depiction of the 
preferred routine for encyrpting a key file which 
contains information including a temporary prod- 
uct key; 

Figure 19 is a block diagram depiction of the 
preferred technique of handling an encryption 
header in an encrypted file, in accordance with 
the present invention; 

Figure 20 depicts in block diagram form the 
technique of utilizing a plurality of inputs in the 
user-controlled data processing system to derive 
the real key which may be utilized to decrypt an 
encrypted software object; 

Figure 21 depicts a decryption operation utiliz- 
ing the real key derived in accordance with 
Figure 20; 

Figure 22 is a block diagram depiction of a 
comparison operation which is utilized to deter- 
mine the validity of the real key; 
Figure 23 depicts a decryption operation utiliz- 
ing a validated real key; 

Figures 24, 25, 26, 27, 28 depict the utilization 
of an encryption header in accordance with the 
present invention; 

Figure 29 is a flowchart representation of the 
preferred technique of providing a trial period of 
use for an encrypted software object; 
Figures 30 and 31 depict export and import 
operations which may be utilized to perform trial 
period use operations in a distributed data pro- 
cessing system; 

Figures 32 and 33 provide an alternative view 
of the import and export operations which are 
depicted in Figures 30 and 31; 
Figures 34 and 35 provide a block diagram 
depiction of an alternative technique for perform- 
ing an export/import operation. 

DETAILED DESCRIPTION OF PREFERRED EM- 
BODIMENT 

The method and apparatus of the present in- 
vention for enabling trail period use of software 
products can be utilized in stand-alone PCs such 
as that depicted in Figure 1, or in distributed data 
processing systems, such as that depicted in Fig- 
ure 2. In either event, temporary trial period access 
to one or more software products depends upon 
utilization of the trial product on a particular data 
processing system with particular data processing 
system attributes. This is accomplished by encryp- 
ting the trial software product utilizing a temporary 
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access key which is based upon one or more data 
processing system attributes. Figure 3 graphically 
depicts a plurality of system configuration at- 
tributes, which may be utilized in developing a 
temporary access key, as will be described in 
greater detail herebelow. To begin with, the envi- 
ronment of the stand-alone data processing system 
of Figure 1, and the distributed data processing 
system of Figure 2 will be described in detail, 
followed by a description of particular system con- 
figuration attributes which are depicted in Figure 3. 

With reference now to the figures and in par- 
ticular with reference to Figure 1, there is depicted 
a pictorial representation of data processing sys- 
tem 10 which may be programmed in accordance 
with the present invention. As may be seen, data 
processing system 10 includes processor 12 which 
preferably includes a graphics processor, memory 
device and central processor (not shown). Coupled 
to processor 12 is video display 16 which may be 
implemented utilizing either a color or monoch- 
romatic monitor, in a manner well known in the art. 
Also coupled to processor 12 is keyboard 14. Key- 
board 14 preferably comprises a standard com- 
puter keyboard which is coupled to the processor 
by means of a cable. 

Also coupled to processor 12 is a graphical 
pointing device, such as mouse 20. Mouse 20 is 
coupled to processor 12, in a manner well known in 
the art, via a cable. As is shown, mouse 20 may 
include left button 24, and right button 26, each of 
which may be depressed, or "clicked", to provide 
command and control signals to data processing 
system 10. While the disclosed embodiment of the 
present invention utilizes a mouse, those skilled in 
the art will appreciate that any graphical pointing 
device such as a light pen or touch sensitive 
screen may be utilized to implement the method of 
the present invention. Upon reference to the fore- 
going, those skilled in the art will appreciate that 
data processing system 10 may be implemented 
utilizing a so-called personal computer, such as the 
Model 80 PS/2 computer manufactured by Interna- 
tional Business Machines Corporation of Armonk, 
New York. 

While the present invention may be utilized in 
stand-alone data processing systems, it may also 
be utilized in a distributed data processing system, 
provided the import and export routines of the 
present invention are utilized to transfer one or 
more encrypted files, their encrypted key files, and 
associated file management programs through a 
portable memory media (such as diskettes or 
tapes) between particular data processing units 
within the distributed data processing system. 
While the import and export routines of the present 
invention will be described in greater detail 
herebelow, it is important that a basic distributed 



data processing system be described and under- 
stood. 

Figure 3 provides a block diagram depiction of 
a plurality of data processing system attributes 
5 which may be utilized to uniquely identify a particu- 
lar data processing system (whether a stand-alone 
or a node in a distributed data processing system), 
and which further can be utilized to generate in the 
machine identification value which is utilized to 
10 derive or generate a temporary access product key 
which may be utilized to gain access to an encryp- 
ted product for a particular predefined trial interval. 
A data processing system may include a particular 
system bus 60 architecture, a particular memory 
75 controller 74, bus controller 76, interrupt controller 
78, keyboard mouse controller 80, DMA controller 
66, VGA video controller 82, parallel controller 84, 
serial controller 86, diskette controller 88, and disk 
controller 82. Additionally, a plurality of empty or 
20 occupied slots 106 may be used to identify the 
particular data processing system. Each particular 
data processing system may have attributes which 
may be derived from RAM 70, ROM 68, or CMOS 
RAM 72. End devices such as printer 96, monitor 
25 94, mouse 92, keyboard 90 ( diskette 100, or disk 
drive 104 may be utilized to derive one or more 
attributes of the data processing system which may 
be processed in a predetermined manner to derive 
a machine identification value. The derivation of the 
30 machine identification value will be described in 
greater detail below. The present invention is di- 
rected to an efficient method of distributing soft- 
ware programs to users which would provide to 
them a means to try the program before obtaining 
35 (by purchasing) a license for it. In accordance with 
this concept, complete programs are distributed to 
potential users on computer-accessible memory 
media such as diskettes or CD-ROMs. The concept 
is to generate keys that allow the user to access 
40 the programs from the distributed media. In this 
environment, a file management program provides 
a plurality of interfaces which allows the user to 
browse the different products. The interfaces allow 
ordering and unlocking of the software products 
45 contained on the distributed media. Unlocking of 
the software product is accomplished by the recep- 
tion, validation, and recording of a temporary ac- 
cess (decryption) key. 

The file management program is resident in 
50 the user-controlled data processing system and 
becomes a part of the operating system in the 
user's computer. An example of such a resident 
program (in the PC DOS environment) would be a 
resident program TSR, for "terminate and stay 
55 resident" operations, that intercepts and handles 
DOS file input and output operations. When a tem- 
porary access key is provided to a user, system 
files are checked to see if this file has been used in 
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a trial mode of operation before. If the product has 
never been used in a trial mode of operation, the 
temporary key is saved. Once the trial mode of 
operation key exists, an encrypted application can 
only be run if it is initiated by the file management 
program. The file management program will recog- 
nize that the application is encrypted and that a 
valid trial mode of operation key exists for the 
particular operation. A valid trial mode of applica- 
tion key is one that has not expired. The trial mode 
of operation may be defined by either a timer, or a 
counter. A timer can be used to count down a 
particular predefined period (such as thirty days); 
alternatively, the counter can be used to decrement 
through a predefined number of trial "sessions" 
which are allowed during the trial mode of opera- 
tion. If the key is valid, the file management pro- 
gram communicates directly with the TSR and en- 
ables the trial mode of operation for a particular 
encrypted application. The file management pro- 
gram then kicks off the encrypted application. The 
code which is resident in the operating system of 
the user-controlled data processing system main- 
tains control over the operating system. It monitors 
the use of the trial mode of operation keys to allow 
files to be decrypted and loaded into memory, but 
prevents the encrypted files from being decrypted 
and copied to media. This is done by using the 
operating system to determine which applications 
are trying to access the data and only allowing the 
applications that have permission to access the 
data to do so. 

Figure 4 is a block diagram depiction of a 
routine for encrypting software objects. The binary 
characters which make up software object 201 are 
supplied as an input to encryption engine 205. Real 
key 203 is utilized as an encryption key in encryp- 
tion engine 205. The output of encryption engine 
205 is an encrypted software object 207. Encryp- 
tion engine 205 may be any conventional encryp- 
tion operation such as the published and well 
known DES algorithm; alternatively, the encryption 
engine 205 may be an exclusive-OR operation 
which randomizes software object 201 . 

Figure 5 is a pictorial representation of the 
exchange of information between a source 209 (a 
software vendor) and a user 211 (a potential cus- 
tomer, in accordance with the teachings of the 
present invention. The arrows between source 209 
and user 211 represent exchanges of objects or 
information between vendor 209 and 211. In the 
exchange of flow 203, computer-accessible mem- 
ory media is directed from source 209 to user 211. 
This transfer may occur by US mail delivery, cou- 
rier delivery, express service delivery, or by deliv- 
ery through printed publications such as books and 
magazines. Alternatively, an electronic document 
may be transferred from source 209 to user 211 
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utilizing electronic mail or other transmission tech- 
niques. In flow 215, user-specific information, pref- 
erably including a unique machine identification 
number which identifies the data processing sys- 

5 tern of user 211, is transferred from user 211 to 
source 209 via an insecure communication chan- 
nel; typically, this information is exchanged over 
the telephone, but may be passed utilizing elec- 
tronic mail or other communication techniques. In 

10 flow 217, source 209 provides a product key to 
user 211. The product key allows the product con- 
tained in the memory media to be temporarily 
accessed for a prescribed and predefined interval. 
This interval is considered to be a "trial" interval 

75 during which user 211 may become familiar with 
the software and make a determination on whether 
or not he or she wishes to purchase the software 
product. User 211 must communicate additionally 
with source 209 in order to obtain permanent ac- 

20 cess to the software product. The product key 
allows user 211 to obtain access to the software 
product for a particular predefined time interval, or 
for a particular number of predefined "sessions." 
As time passes, the user's clock or counter runs 

25 down. At the termination of the trial period, further 
access is denied. Therefore, the user 211 must 
take affirmative steps to contact source 209 and 
purchase a permanent key which is communicated 
to user 211 and which permanently unlocks a prod- 

30 uct to allow unrestricted access to the software 
product. 

The communication between source 209 and 
user 211 is facilitated by a user interface. The 
creation of the interface is depicted in flowchart 

35 form in Figure 6. The process begins at software 
block 219, and continues at software block 221, 
wherein source 209 makes language and locale 
selections which will determine the language and 
currencies utilized in the interface which facilitates 

40 implementation of the trial period use of the soft- 
ware products. A plurality of software products may 
be bundled together and delivered to user 211 on a 
single computer-accessible memory media. There- 
fore, in accordance with software block 223, source 

45 209 must make a determination as to the programs 
which will be made available on a trial basis on the 
computer-accessible memory media, and the ap- 
propriate fields are completed, in accordance with 
software block 223. Next, in accordance with soft- 

50 ware block 225, the programs are functionally limit- 
ed or encrypted. Then, in accordance with software 
block 227, the shell is loaded along with the com- 
puter program products onto a computer-acces- 
sible memory media such as a diskette or CD 

55 ROM. The process ends at software block 229. 

Figure 7 is a flowchart representation of ven- 
dor and customer interaction in accordance with 
the present invention. The flow begins at software 

7 
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block 231, and continues at step 233, wherein 
computer-accessible memory media are distributed 
to users for a try-and-buy trial interval. Then, in 
accordance with step 235, the file management 
program is loaded from the computer-accessible 
memory media onto a user-controlled data pro- 
cessing system for execution. The file management 
program includes a plurality of interface screens 
which facilitate interaction between the vendor and 
the customer, which and which set forth the options 
available to the customer. Thus, in accordance with 
step 237, the file management program allows 
browsing and displays appropriate user interfaces. 
Next, in accordance with step 239, the customer 
and the vendor interact, typically over the tele- 
phone or electronic mail, to allow the vendor to 
gather information about the customer and to dis- 
tribute a temporary key which allows access to one 
or more software products which are contained on 
the computer-accessible memory media for a 
predefined trial interval. Typically, the interval will 
be defined by an internal clock, or by a counter 
which keeps track of the number of sessions the 
potential purchaser has with a particular software 
product or products. Step 241 represents the al- 
lowance of the trial interval use. Then, in accor- 
dance with software block 243, the file manage- 
ment program monitors and oversees all input and 
output calls in the data processing system to pre- 
vent unauthorized use of the encrypted software 
products contained on the computer-accessible 
memory media. In the preferred embodiment of the 
present invention, the file management program 
monitors for calls to encrypted files, and then de- 
termines whether access should be allowed or de- 
nied before the file is passed for further process- 
ing. The customer can assess the software product 
and determine whether he or she desires to pur- 
chase it. If a decision is made to purchase the 
product, the customer must interact once again 
with the vendor, and the vendor must deliver to the 
customer a permanent key, as is set forth in step 
245. The process ends when the customer re- 
ceives the permanent key, decrypts the one or 
more software products that he or she has pur- 
chased, and is then allowed ordinary and unrestric- 
ted access to the software products. 

Figures 8, 9, 10a, and 10b depict user inter- 
face screens which facilitate trial period operations 
in accordance with the present invention. Figure 8 
depicts an order form user interface 249 which is 
displayed when the customer selects a "view or- 
der" option from another window. The order form 
user interface 249 includes a title bar 251 which 
identifies the software vendor and provides a tele- 
phone number to facilitate interaction between the 
potential customer and the vendor. An order form 
field 255 is provided which identifies one or more 



software products which may be examined during 
a trial interval period of operation. A plurality of 
subfields are provided including quantity subfieid 
259, item subfieid 257, description subfieid 260, 
5 and price subfieid 253. Delete button 261 allows 
the potential customer to delete items from the 
order form field. Subtotal field 263 provides a sub- 
total of the prices for the ordered software. Pay- 
ment method icons 265 identify the acceptable 
70 forms of payment. Of course, a potential user may 
utilize the telephone number to directly contact the 
vendor and purchase one or more software pro- 
ducts; alternatively, the user may select one or 
more software products for a trial period mode of 
75 operation, during which a software product is ex- 
amined to determine its adequacy. A plurality of 
function icons 267 are provided at the lowermost 
portion of order form interface 249. These include a 
close icon, fax icon, mail icon, print icon, unlock 
20 icon, and help icon. The user may utilize a graphi- 
cal pointing device in a conventional point-and-click 
operation to select one or more of these oper- 
ations. The fax icon facilitates interaction with the 
vendor utilizing a facsimile machine or facsimile 
25 board. The print icon allows the user to generate a 
paper archival copy of the interaction with the 
software vendor. 

The customer, the computer-accessible mem- 
ory media, and the computer system utilized by 
30 the customer are identified by media identification 
269, customer identification 273, and machine 
identification 271. The media identification is as- 
signed to the computer-accessible memory media 
prior to shipping to the potential customer. It is 
35 fixed, and cannot be altered. The customer iden- 
tification 273 is derived from interaction between 
the potential customer and the vendor. Preferably, 
the customer provides answers to selected ques- 
tions in a telephone dialogue, and the vendor sup- 
40 plies a customer identification 273, which is unique 
to the particular customer. The machine identifica- 
tion 271 is automatically derived utilizing the file 
management program which is resident on the 
computer-accessible memory media, and which is 
45 unique to the particular data processing system 
being utilized by the potential customer. The po- 
tential customer will provide the machine identifica- 
tion to the vendor, typically through telephone in- 
teraction, although fax interaction and regular mail 
50 interaction is also possible. 

Figure 9 is a representation of an order form 
dialog interface 275. This interface facilitates the 
acquisition of information which uniquely identifies 
the potential customer, and includes name field 
55 277, address field 279, phone number field 281, 
facsimile number field 283, payment method field 
285, shipping method field 287, account number 
field 289, expiration date field 291, value added tax 
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ID field 293. Order information dialog interface 275 
further includes print button 295 and cancel button 
297 which allow the potential user to delete in- 
formation from these fields, or to print a paper 
copy of the interface screen. 

Figures 10a and 10b depict unlock dialog in- 
terface screens 301, 303. The user utilizes a 
graphical pointing device to select one or more 
items which are identified by the content item 
number field 307 and description field 309 which 
are components of unlock list 305. The interface 
further includes customer ID field 313 and machine 
ID field 315. Preferably, the vendor provides the 
customer identification to the customer in an inter- 
action via phone, fax, or mail. Preferably, the cus- 
tomer provides to the vendor the machine iden- 
tification within machine identification field 315 dur- 
ing interaction via phone, fax, or mail. Once the 
information is exchanged, along with an identifica- 
tion of the products which are requested for a trial 
interval period of operation, a temporary access 
key is provided which is located within key field 
311. The key will serve to temporarily unlock the 
products identified and selected by the customer. 
Close button 319, save button 317, and help button 
321 are also provided in this interface screen to 
facilitate user interaction. 

Figure 10b depicts a single-product unlock 
interface screen 303. This interface screen includes 
only machine identification field 315, customer 
identification field 315, and key field 311. The prod- 
uct which is being unlocked need not be identified 
in this interface, since the dialog pertains only to a 
single product, and it is assumed that the user 
knows the product for which a temporary trial pe- 
riod of operation is being requested. Save button 
317, cancel button 319, and help button 321 are 
also provided in this interface to facilitate operator 
interaction. 

Figure 11 depicts a user interface screen 
which is utilized in unlocking the one or more 
encrypted products for the commencement of a 
trial interval mode of operation. The starting date 
dialog of Figure 11 is displayed after the "SAVE" 
push button is selected in the unlock dialog of 
either Figure 10a or Figure 10b. The user will be 
prompted to verify the correct starting date which 
is provided in date field 310. The user responds to 
the query by pointing and clicking to either the 
"continue" button 312, the "cancel" button 314, or 
the "help" button 316. The date displayed in field 
310 is derived from the system clock of the user- 
controlled data processing system. The user may 
have to modify the system clock to make the date 
correspond to the official or stated date of com- 
mencement of the trial period of operation. 

A trial interval operation can take two forms: 
one form is a functionally disabled product that 



BNSDOCID: <EP 0679980A1 J_> 



allows a user to try all the features, but may not 
allow a critical function like printing or saving of 
data files. Another type of trial interval is a fully 
functional product that may be used for a limited 
5 time. This requires access protection, and allows a 
customer to try all the functions of a product for 
free or for a nominal fee. Typically, in accordance 
with the present invention, access to the product is 
controlled through a "timed" key. The trial period 
io for using the product is a fixed duration determined 
by the vendor. The trial period begins when the 
key is issued. In accordance with the present in- 
vention, the products being previewed during the 
trial interval of operation can only be run from 
75 within a customer shell. A decryption driver will not 
allow the encrypted products to be copied in the 
clear, nor will it allow the product to be run outside 
the customer's shell. In an alternative embodiment, 
the trial interval is defined by a counter which is 
20 incremented or decremented with each "session" 
the customer has with the product. This may allow 
the customer a predefined number of uses of the 
product before decryption is no longer allowed with 
the temporary key. 
25 The limits of the temporary access key are 

built into a "control vector" of the key. Typically, a 
control vector will include a short description of the 
key, a machine identification number, and a for- 
matted text string that includes the trial interval 
30 data (such as a clock value or a counter value). 
The control vector cannot be altered without break- 
ing the key. When a protected software product is 
run, the usage data must be updated to enforce the 
limits of the trial interval period of operation. In 
35 order to protect the clock or counter from tamper- 
ing, its value is recorded in a multiple number of 
locations, typically in encrypted files. In the pre- 
ferred embodiment of the present invention, the 
trial interval information (clock value and/or counter 
40 value) is copied to a "key file" which will be 
described in further detail herebeiow, to a machine 
identification file, which will also be discussed 
herebeiow, and to a system file. When access to 
an encrypted program is requested, all of these 
45 locations are checked to determine if the value for 
the clock and/or counter is the same. It is unlikely 
that an average user has the sophistication to tam- 
per successfully with all three files. In the preferred 
embodiment, a combination of a clock and a coun- 
50 ter is utilized to prevent extended use of backup 
and restore operations to reset the system clock. 
Although it is possible to reset a PC's clock each 
time a trial use is requested, this can also be 
detected by tracking the date/time stamps of cer- 
55 tain files on the system and using the most recent 
dale between file date/lime stamps and the system 
clock. As stated above, one of the three locations 
the timer and/or counter information is stored is a 
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system file. When operating in an OS/2 operating 
system, the time and usage data can be stored in 
the system data files, such as the OS2.INI in the 
OS/2 operating system. The user will have to con- 
tinuously backup and restore these files to reset 
the trial and usage data. These files contain other 
data that is significant to the operation of the user 
system. The casual user can accidentally lose im- 
portant data for other applications by restoring 
these files to an older version. In the present inven- 
tion, these protection techniques greatly hinder a 
dishonest user's attempts to extend the trial interval 
use beyond the authorized interval. 

In broad overview, in the present invention, the 
— vWdOT^oa^s-a"p1uTalrry^ 
ducts onto a computer-accessible memory media, 
such as a CD ROM or magnetic media diskette. 
Also loaded onto the computer-accessible memory 
media is a file management program which per- 
forms a plurality of functions, including the function 
of providing a plurality of user interface screens 
which facilitate interaction between the software 
vendor and the software customer. The computer- 
accessible memory media is loaded onto a user- 
controlled data processing system, and the file 
management program is loaded for execution. The 
file management program provides a plurality of 
user-interface screens to the software customer 
which gathers information about the customer 
(name, address, telephone number, and billing in- 
formation) and receives the customer selections of 
the software products for which a trial interval is 
desired. Information is exchanged between the 
software vendor card customer, including: a cus- 
tomer identification number, a product identification 
number, a media identification number, and a ma- 
chine identification number. The vendor generates 
the customer identification number in accordance 
with its own internal record keeping. Preferably, the 
representative of the software vendor gathers in- 
formation from the software customer and types 
this information into a established blank form in 
order to identify the potential software customer. 
Alternatively, the software vendor may receive a 
facsimile or mail transmission of the completed 
order information dialog interface screen 275 (of 
Figure 9). The distributed memory media (such as 
CDs and diskettes) also include a file management 
program which is used to generate a unique ma- 
chine identification based at least in part upon one 
attribute of the user-controlled data processing sys- 
tem. This machine identification is preferably a 
random eight-bit number which is created during a 
one-time setup process. Preferably, eight random 
bits are generated from a basic random number 
generator using the system time as the "seed" for 
the random number generator. Preferably, check 
bits are added in the final result. Those check bits 



are critical to the order system because persons 
taking orders must key in the machine ID that the 
customer reads over the phone. The check bits 
allow for instant verification of the machine ID with- 
5 out requiring the customer to repeat the number. 
Preferably, a master file is maintained on the user- 
controlled data processing system which contains 
the clear text of the machine identification and an 
encrypted version of the machine identification. 
10 When the software customer places an order 

for a temporary trial use of the software products, 
he or she verbally gives to the telephone repre- 
sentative of the software vendor the machine iden- 
tification. In return, the telephone representative 

- r5 gives-the-software- wst^ 

serves as a temporary access key to the encrypted 
software products on the computer-accessible 
memory media, as well as a customer identification 
number. Preferably, the product key is a function of 
20 the machine identification, the customer number, 
the real encryption key for the programs or pro- 
grams ordered, and a block of control data. The 
software customer may verity the product key by 
combining it with the customer number, and an 
25 identical block of control data to produce the real 
encryption key. This key is then used to decrypt an 
encrypted validation segment, to allow a compare 
operation. If the encrypted validation segment is 
identical to known clear text for the validation seg- 
30 ment, then the user's file management program 
has determined that the product key is a good 
product key and can be utilized for temporary 
access to the software products. Therefore, if the 
compare matches, the key is stored on the user- 
35 controlled data processing system in a key file. 
Preferably, the key file contains the product key, a 
customer key (which is generated from the cus- 
tomer number and an internal key generating key) 
and a clear ASCII string containing the machine 
40 identification. All three items must remain un- 
changed in order for the decryption tool to derive 
the real encryption key. To further tie the key file to 
this particular user-controlled data processing sys- 
tem, the same key file is encrypted with a key that 
45 is derived from system parameters. These system 
parameters may be derived from the configuration 
of the data processing system. 

Stated broadly, in the present invention the 
temporary key (which is given verbally over the 
so phone, typically) is created from an algorithm that 
utilizes encryption to combine the real key with a 
customer number, the machine identification num- 
ber, and other predefined clear text. Thus, the key 
is only effective for a single machine: even if the 
55 key were to be given to another person, it would 
not unlock the program on that other person's 
machine. This allows the software vendor to market 
software programs by distributing complete pro- 
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grams on computer-accessible memory media 
such as diskettes or CD ROMs, without significant 
risk of the loss of licensing revenue. 

Some of the preferred unique attributes of the 
system which may be utilized for encryption oper- 5 
ations include the hard disk serial number, the size 
and format of the hard disk, the system model 
number, the hardware interface cards, the hardware 
serial number, and other configuration parameters. 
The result of this technique is that a machine 10 
identification file can only be decrypted on a sys- 
tem which is an identical clone of the user-con- 
trolled data processing system. This is very difficult 
to obtain, since most data processing systems 

h ave-drt f er emt-corrfig u rations rand-the-eonftguf-ati on s 75- 

can only be matched through considerable effort. 
These features will be described in detail in the 
following written description. 

Turning now to Figure 12, the file management 
program receives the distributed computer-acces- 20 
sible memory media with encrypted software pro- 
ducts and a file management program contained 
therein. The file management program assesses 
the configuration of the user-controlled data pro- 
cessing system, as represented in step 351 of 25 
Figure 12. The user-specific attributes of the data 
processing system are derived in step 353, and 
provided as an input to machine identification gen- 
erator 355, which is preferably a random number 
generator which receives a plurality of binary char- 30 
acters as an input, and generates a pseudo-random 
output which is representative of machine iden- 
tification 357. The process employed by machine 
identification generator 355 is any conventional 
pseudo-random number generator which receives 35 
as an input of binary characters, and produces as 
an output a plurality of pseudo-random binary char- 
acters, in accordance with a predefined algorithm. 

With reference now to Figure 13, machine 
identification 357 is also maintained within the file 40 
management program in an encrypted form. Ma- 
chine identification 357 is supplied as an input to 
encryption engine 359 to produce as an output the 
encrypted machine identification 361. Encryption 
engine 359 may comprise any convention encryp- 45 
tion routine, such as the DES algorithm. A key 353 
is provided also as an input to encryption engine 
359, and impacts the encryption operation in a 
conventional manner. Key 363 is derived from sys- 
tem attribute selector 365. The types of system 50 
attributes which are candidates for selection in- 
clude system attribute listing 367 which includes: 
the hard disk serial number, the size of the hard 
disk, the format of the hard disk, the system model 
number, the hardware interface card, the hardware 55 
serial number, or other configuration parameters. 

In accordance with the present invention, the 
clear text machine identification 357 and the en- 



crypted machine identification 361 are maintained 
in memory. Also, in accordance with the present 
invention, the file management program automati- 
cally posts the clear text machine identification 357 
to the appropriate user interface screens. The user 
then communicates the machine identification to 
the software vendor where it is utilized in accor- 
dance with the block diagram of Figure 14. As is 
shown, product key encryption engine 375 is main- 
tained within the control of the software vendor. 
This product key encryption engine 375 receives 
as an input: the machine identification 357, a cus- 
tomer number 369 (which is assigned to the cus- 
tomer in accordance with the internal record keep- 
-ing-of^thrs-softwafe von do r^ne-reat-enefyption -key- 
371 (which is utilized to decrypt the software pro- 
ducts maintained on the computer-accessible 
memory media within the custody of the software 
customer), a control block test 373 (which can be 
any predefined textural portion), and trial interval 
data 374 (such as clock and/or counter value which 
defines the trial interval of use). Product key en- 
cryption engine produces as an output a product 
key 377. Product key 377 may be communicated 
to the software customer via an insecure commu- 
nication channel, without risk of revealing real key 
371. Real key 371 is masked by the encryption 
operation, and since the product key 377 can only 
be utilized on a data processing system having a 
configuration identical to that from which machine 
identification 357 has been derived, access to the 
encrypted software product is maintained in a se- 
cure condition. 

Upon delivery of product key 377, the file man- 
agement program resident in the user-controlled 
data processing system utilizes real key generator 
379 to receive a plurality of inputs, including prod- 
uct key 377, customer number 369, control block 
test 373, machine identification 357 and trial inter- 
val data 374. Real key generator 379 produces as 
an output the derived real key 381 . 

Encryption and decryption algorithm utilized to 
perform the operations of the product key encryp- 
tion engine 375 and the real key generator 379 (of 
Figures 14 and 15) is described and claimed in 
co-pending U.S. Patent Application Serial No. 
07/964,324, filed October 21, 1992, entitled "Meth- 
od and System for Multimedia Access Control En- 
ablement", which is incorporated herein as if fully 
set forth. 

Next, as is depicted in Figures 16 and 17, the 
derived real key 381 is tested to determine the 
validity and authenticity of the product key 377 
which has been provided by the software vendor. 
As is shown, the derived real key 381 is supplied 
as an input to encryption engine 385. A predeter- 
mined encrypted validation data segment 383 is 
supplied as the other input to encryption engine 
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385. Encryption engine supplies as an output de- 
rived clear validation text 387. Then, in accordance 
with Figure 17, the derived clear validation text 
387 is compared to the known clear validation text 
391 in comparator 389. Comparator 389 simply 
performs a bit-by-bit comparison of the derived 
clear validation text 387 with the known clear vali- 
dation text 391. If the derived clear validation text 
387 matches the known clear validation text 391, a 
key file is created in accordance with step 393; 
however, if the derived clear validation text 387 
does not match the known clear validation text 391, 
a warning is posted to the user-controlled data 
processing system in accordance with step 395. 

Turning now to Figure 18, key file 397 is 
depicted as including the temporary product key, 
the customer key (which is an encrypted version of 
the customer number), the machine identification 
number in clear text and the trial interval data (such 
as a clock and/or counter value) . This key file is 
supplied as an input to encryption engine 399. Key 
401 is also provided as an input to encryption 
engine 399. Key 401 is derived from unique sys- 
tem attributes 403. such as those system attributes 
utilised in deriving the machine identification num- 
ber. Encryption engine 399 provides as an output 
the encrypted key file 405. 

Figures 19, 20, 21, 22, and 23 depict oper- 
ations of the file management program after a 
temporary access key has been received, and vali- 
dated, and recorded in key file 397 (of Figure 18). 

Figure 19 is a block diagram representation of 
the steps which are performed when an encrypted 
software product is called for processing by the 
user-control data processing system. The encryp- 
ted file 405 is fetched, and a "header" portion 407 
is read by the user-controlled data processing sys- 
tem. The header has a number of components 
including the location of the key file. The location 
of the key file is utilized to fetch the key file in 
accordance with step 409. The header further in- 
cludes an encrypted validation text 411. The en- 
crypted validation text 411 is also read by the user- 
controlled data processing system. As is stated 
above (and depicted in Figure 18) the key file 
includes the product key 419, a customer key 417, 
and the machine identification 415. These are ap- 
plied as inputs to decryption engine 413. Decryp- 
tion engine 413 provides as an output real key 421. 
Before real key 421 is utilized to decrypt encrypted 
software products on the distributed memory me- 
dia, it is tested to determine its validity. Figure 21 
is a block diagram of the validation testing. Encryp- 
ted validation text 423, which is contained in the 
"header", is provided as an input to decryption 
engine 425. Real key 421 (which was derived in 
the operation of Figure 20) is also supplied as an 
input to decryption engine 425. Decryption engine 



425 provides as an output clear validation text 427. 
As is set forth in block diagram form in Figure 22, 
clear validation text 427 is supplied as an input to 
comparator 429. The known clear validation text 
5 431 is also supplied as an input to comparator 429. 
Comparator 429 determines whether the derived 
clear validation text 427 matches the known clear 
validation text 431. If the texts match, the software 
object is decrypted in accordance with step 433; 
io however, if the validation text portions do not 
match, a warning is post in accordance with step 
435. Figure 23 is a block diagram depiction of the 
decryption operation of step 433 of Figure 22. The 
encrypted software object 437 is applied as an 
75 input to decryption engine 439. The validated real 
key 441 is also supplied as an input to decryption 
engine 439. Decryption engine 439 supplies as an 
output the decrypted software object 443. 

The encryption header is provided to allow for 
20 the determination of whether or not a file is encryp- 
ted when that file is stored with clear-text files. In 
providing the encryption header for the encrypted 
file, it is important that the file size not be altered 
because the size may be checked as part of a 
25 validation step (unrelated in any way to the concept 
of the present invention) during installation. There- 
fore, making the file larger than it is suppose to be 
can create operational difficulties during installation 
of the software. The encryption header is further 
30 necessary since the file names associated with the 
encrypted software products cannot be modified to 
reflect the fact that the file is encrypted, because 
the other software applications that may be acces- 
sing the encrypted product will be accessing those 
35 files utilizing the original file names. Thus, altering 
the file name to indicate that the file is encrypted 
would prevent beneficial and desired communica- 
tion between the encrypted software product and 
other, perhaps related, software products. For ex- 
40 ample, spreadsheet applications can usually port 
portions of the spreadsheet to a related word pro- 
cessing program to allow the integration of financial 
information into printed documents. Changing the 
hard-coded original file name for the word process- 
45 ing program would prevent the beneficial commu- 
nication between these software products. The en- 
cryption header of the present invention resolves 
these problems by maintaining the encrypted file at 
its nominal file length, and by maintaining the file 
50 name for the software product in an unmodified 
form. 

Figure 24 graphically depicts an encrypted file 
with encryption header 451. The encryption header 
451 includes a plurality of code segments, includ- 
55 ing: unique identifier portion 453, the name of the 
key file portion 455, encrypted validation segment 
457, encryption type 459, offset to side file 461, 
and encrypted file data 463. Of course, in this view, 
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the encrypted file data 463 is representative of the 
encrypted software product, such as a word pro- 
cessing program or spreadsheet. The encryption 
header 451 is provided in place of encrypted data 
which ordinarily would comprise part of the encryp- 
ted software product. The encryption header is 
substituted in the place of the first portion of the 
encrypted software product. In order to place the 
encryption header 451 at the front of the encrypted 
software product of encrypted file data 463, a por- 
tion of the encrypted file data must be copied to 
another location. Offset to side file 461 identifies 
that side file location where the displaced file data 
is contained. 

Figure 25 graphically depicts the relationship 
between the directory of encrypted files and the 
side files. As is shown, the directory of encrypted 
files 465 includes file aaa, file bbb, file ccc, file 
ddd, through file nnn. Each of these files is repre- 
sentative of a directory name for a particular en- 
crypted software product. Each encrypted software 
product has associated with it a side file which 
contains the front portion of the file which has been 
displaced to accommodate encryption header 451 
without altering the size of the file, and without 
altering the file name. File aaa has associated with 
it a side file AAA. Software product file bbb has 
associated with it a side file BBB. Encrypted soft- 
ware product ccc has associated with it a side file 
CCC. Encrypted software product ddd has asso- 
ciated with it a side file DDD. Encrypted software 
product nnn has associated with it a side file NNN. 
In Figure 25, directory names 467, 469, 471, 473, 
475 are depicted as being associated with side 
files 477, 479, 481, 483, and 485. The purpose of 
the side files is to allow each of the encrypted 
software products to be tagged with an encryption 
header without changing the file size. 

Encryption type segment 459 of the encryption 
header 451 identifies the type of encryption utilized 
to encrypt the encrypted software product. Any one 
of a number of conventional encryption techniques 
can be utilized to encrypt the product, and different 
encryption types can be utilized to encrypt different 
software products contained on the same memory 
media. Encryption type segment 459 ensures that 
the appropriate encryption/decryption routine is 
called so that the encrypted software product may 
be decrypted, provided the temporary access keys 
are valid and not expired. The name of key file 
segment 455 of encryption header 451 provides an 
address (typically a disk drive location) of the key 
file. As is stated above (in connection with Figure 
18) the key file includes the product key, a cus- 
tomer key, and the clear machine ID. All three of 
these pieces of information are required in order to 
generate the real key (in accordance with Figure 
20). Encrypted validation segment 457 includes the 



encrypted validation text which is utilized in the 
routine depicted in Figure 21 which generates a 
derived clear validation text which may be com- 
pared utilizing the routine of Figure 22 to the 

5 known clear validation text. Only if the derived 
clear validation text exactly matches the known 
clear validation text can the process continue by 
utilizing the derived and validated real key to de- 
crypt the encrypted software product in accordance 

io with the routine of Figure 23. However, prior to 
performing the decryption operations of Figure 23, 
the contents of the corresponding side file must be 
substituted back into the encrypted software prod- 
uct in lieu of encryption header 451. This ensures 

75 that the encrypted software product is complete 
prior to the commencement of decryption oper- 
ations. 

Each time a file is called for processing by the 
operating system of the user-controlled data pro- 

20 cessing system, the file management program 
which is resident in the operating system intercepts 
the input/output requests and examines the front 
portion of the file to determine if a decryption block 
identifier, such as unique identifier 453, exists at a 

25 particular known location. For best performance, as 
is depicted in Figure 24, this location will generally 
be at the beginning of the file. If the file manage- 
ment program determines that the file has the 
decryption block, the TSR will read the block into 

30 memory. The block is then parsed in order to build 
a fully qualified key file name by copying an envi- 
ronment variable that specifies the drive and direc- 
tory containing the key files and concatenating the 
key file name from the encryption block. The TSR 

35 then attempts to open the key file. If the key file 
does not exist, the TSR returns an "access denied" 
response to the application which is attempting to 
open the encrypted file. If the key file is deter- 
mined to exist, the TSR opens the key file and 

40 reads in the keys (the product key, the customer 
key, and the machine identification) and generates 
the real key. This real key is in use to decrypt the 
decryption block validation data. As is stated 
above, a comparison operation determines whether 

45 this decryption operation was successful. If the 
compare fails, the key file is determined to be 
"invalid", and the TSR returns an "access denied 
message" to the application which is attempting to 
open the encrypted software product. However, if 

so the compare is successful, the file management 
program prepares to decrypt the file according to 
the encryption type found in the encryption header. 
The TSR then returns a valid file handle to the 
calling application to indicate that the file has been 

55 opened. When the application reads data from the 
encrypted file, the TSR reads and decrypts this 
data before passing it back to the application. If the 
data requested is part of the displaced data that is 
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stored in the side file, the TSR will read the side 
file and return the appropriate decrypted block to 
the calling application without the calling applica- 
tion being aware that the data came from a sepa- 
rate file. 

While the broad concepts of the encryption 
header are depicted in Figures 24 and 25. the 
more particular aspects of creating the encrypted 
files are depicted in Figures 26, 27, and 28. Fig- 
ures 27 and 28 depict two types of data files. 
Figure 27 depicts a non-executing data file, while 
Figure 28 depicts an executing data file. Figure 26 
depicts a header 499 which includes signature seg- 
ment 501, header LEN 503, side file index 505, 
side file LEN 507. decryption type identifier 509, 
verification data 511, and key file name 518. As is 
shown in Figure 27, a software product begins as 
a clear file 521. and is encrypted in accordance 
with a particular encryption routine into encrypted 
file 523. Encryption type segment 509 of header 
499 identifies the type of encryption utilized to 
change clear file 521 to encrypted file 523. Next, 
the front portion of encrypted file 523 is copied to 
side file 527 which is identified by side file index 
505 and side file LEN 507 of header 499. Addition- 
ally a copy of the clear text of the verification data 
is also included in side file 527. Then, header 499 
is copied to the front portion of encrypted file 523 
to form modified encrypted files 525. A similar 
process is employed for executing files, as de- 
picted in Figure 28. The clear text copy of the 
software product (represented as clear file 531) is 
encrypted in accordance with a conventional rou- 
tine, to form encrypted file 533. The front portion of 
encrypted file 533 is copied to side file 539 so that 
the overlaid data of encrypted file 533 is preserved. 
Furthermore, side file 539 includes a copy of the 
clear text of the verification data. Then, the encryp- 
ted file 533 is modified by overlaying and execut- 
able stub 537 and header 599 onto the first portion 
of encrypted file 553. 

The purpose of executable stub 537 of Figure 
28 will now be described. The DOS operating sys- 
tem for a personal computer will try to execute an 
encrypted application. This can result in a system 
"hang" or unfavorable action. The executable stub 
357 of the executing file of Figure 28 is utilized to 
protect the user from attempting to execute ap- 
plications that are encrypted: there would be con- 
siderable risk that a user would hang his system or 
format a drive if he or she try to run an encrypted 
file. The executable stub is attached to the front 
portion of the encrypted software product so that 
this stub is executed whenever the application is 
run without the installed TSR or run from a drive 
the TSR is not "watching". This stub will post a 
message to the user that explains why the applica- 
tion cannot run. In addition to providing a message, 



this executable stub can be used to perform so- 
phisticated actions, such as: 

(1 ) it can duplicate the functionality of the TSR 
and install dynamic encryption before kicking off 

5 the application a second time; 

(2) it can turn on a temporary access key and 
kick off the application a second time; 

(3) it can communicate with the TSR and inform 
it to look at the drive the application is being run 

10 from. 

The executable stub is saved or copied into the 
encrypted program as follows: 

(1) the application is encrypted; 

(2) a decryption block is created for this pro- 

75 gram; 

(3) a pre-built executable stub is attached to the 
front end of the decryption block; 

(4) the length of the combined decryption head- 
er and executable stub is determined; 

20 (5) the bytes at the front of the executable file 
equal to this length are then read into memory, 
preferably into a predefined side file location; 
and 

(6) the encryption header and executable stub 
25 are then written over the leading bytes in the 
executable code. 
The TSR can determine if an executable is 
encrypted by searching beyond the "known size" 
of the executable stub for the decryption block 
30 portion. When the TSR decrypts the executable 
stub it accesses the side file to read in the bytes 
that were displaced by the stub and header block. 

Figure 29 provides a flowchart representation 
of operation during a trial period interval, which 
35 begins at software block 601. In accordance with 
software block 603, the file management program 
located in the operating system of the user-con- 
trolled data processing system continually monitors 
for input/output calls to the memory media. Then, 
40 in accordance with software block 605, for each 
input/output call, the called file is intercepted, and 
in accordance with software block 607 the operat- 
ing system is denied access to the called file, until 
the file management program can determine 
45 whether access should be allowed or not. A portion 
of the called file is read where the decryption block 
should be located. This portion of the called file is 
then read, in accordance with software block 609, 
to derive a key file address in accordance with 
so software block 611. The address which is derived 
is utilized to fetch the key file, in accordance with 
software block 613. In accordance with decision 
block 615, if the key file cannot be located, the 
process ends at software block 617; however, if it 
55 is determined in decision block 615 that the key 
file can be located, the key is derived in accor- 
dance with software block 619. The derived key is 
then utilized to decrypt the validation segment 
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which is located within the encryption header, in 
accordance with software block 621. In decision 
block 623, the decryption validation segment is 
compared to the dear text for the decryption valida- 
tion segment; if it is determined that the decrypted 
segment does not match the known clear text 
segment, the process continues at software block 
625 by ending; however, if it is determined in 
decision block 623 that the decrypted validation 
segment does match the known clear text valida- 
tion segment, the process continues as software 
block 627, wherein access to the called file is 
allowed. Then, the decryption type is read from the 
decryption header in accordance with software 
block 629, and the called file is dynamically de- 
crypted in accordance with software block 631 as it 
is passed for processing by the operating system 
of the user-controlled data processing system, in 
accordance with software block 633. The process 
terminates at software block 635. 

If unauthorized execution of an encrypted file is 
attempted, the executable stub will at least tem- 
porarily deny access and post a message to the 
system, but may handle the problem in a number 
of sophisticated ways which were enumerated 
above. 

In accordance with the preferred embodiment 
of the present invention, during the trial interval, or 
at the conclusion of the trial interval, the prospec- 
tive purchaser may contact the vendor to make 
arrangements for the purchase of a copy of the one 
or more software products on the computer- acces- 
sible memory media. Preferably, CD ROMs or flop- 
py disks have been utilized to ship the Product to 
the potential user. Preferably, the computer-acces- 
sible memory media includes the two encrypted 
copies of each of the products which are offered 
for a trial interval of use. One encrypted copy may 
be decrypted utilizing the file management pro- 
gram and the temporary key which is commu- 
nicated from the vendor to the purchaser. The 
other encrypted copy is not provided for use in the 
trial interval mode of operation, but instead is pro- 
vided as the permanent copy which may be de- 
crypted and utilized once the software product has 
been purchased. In broad overview, the user se- 
lects a software product for a trial interval mode of 
operation, and obtains from the vendor temporary 
access keys, which allow the user access to the 
product (through the file management program) for 
a predefined trial interval. Before or after the con- 
clusion of the trial interval, the user may purchase 
a permanent copy of the software product from the 
vendor by contacting the vendor by facsimile, elec- 
tronic mail, or telephone. Once payment is re- 
ceived, the vendor communicates to the user a 
permanent access key which is utilized to decrypt 
the second encrypted copy of the software prod- 



uct. This encrypted product may be encrypted 
utilizing any conventional encryption routine, such 
as the DES algorithm. The permanent key allows 
the software product to be decrypted for unrestric- 

5 ted use. Since multiple copies of the product may 
be purchased in one transaction, the present inven- 
tion is equipped with a technique for providing 
movable access keys, which will be discussed be- 
low in connection with Figures 30 through 35. In 

io the preferred embodiment of the present invention, 
the encryption algorithm employed to encrypt and 
decrypt the second copy of the software product is 
similar to that employed in the trial interval mode of 
operation. 

15 The present invention includes an export/import 

function which allows for the distribution of perma- 
nent access keys, after the conclusion of a trial 
interval period. Typically, an office administrator or 
data processing system manager will purchase a 

20 selected number of "copies" of the encrypted 
product after termination of a trial interval period. 
Certain individuals within the organization will then 
be issued permanent keys which allow for the 
unrestricted and permanent access to the encryp- 

25 ted product. In an office or work environment where 
the computing devices are not connected in a 
distributed data processing network, the permanent 
access keys must be communicated from the of- 
fice administrator or data processing manager to 

30 the selected individuals within an organization who 
are going to receive copies of the encrypted soft- 
ware product. The permanent keys allow for per- 
manent access to the product. Since not all em- 
ployees within an organization may be issued 

35 copies of the particular encrypted product, the ven- 
dor would like to have the distribution occur in a 
manner which minimizes or prevents the distribu- 
tion beyond the sales agreement or license agree- 
ment. Since the products are encrypted, they may 

40 be liberally distributed in their encrypted form. It is 
the keys which allow unrestricted access to the 
product which are to be protected in the current 
invention. To prevent the distribution of keys on 
electronic mail or printed communications, the 

45 present invention includes an export program which 
is resident in a source computer and an import 
program which is resident in a target computer 
which allow for the distribution of the access keys 
via a removable memory media, such as a floppy 

50 diskette. This ensures that the access keys are not 
subject to inadvertent or accidental distribution or 
disclosure. There are two principal embodiments 
which accomplish this goal. 

In the first embodiment, one or more encrypted 

55 files which are maintained in the source computer 
are first decrypted, and then encrypted utilizing an 
encryption algorithm and an encryption key which 
is unique to the transportable memory media (such 
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as a diskette serial number). The key file may then 
be physically carried via the diskette to a target 
computer, where it is decrypted utilizing a key 
which is derived by the target computer from inter- 
action with the transferable memory media. Imme- 
diately, the key file or files are then encrypted 
utilizing an encryption operation which is keyed 
with a key which is derived from a unique system 
attribute of the target computer. 

In the alternative embodiment, the transferrable 
memory media is loaded onto the target computer 
to obtain from the target computer import file a 
transfer key which is uniquely associated with the 
target computer, and which may be derived from 
one or~ more unique~system-attributes- of "the target- 
computer. The memory media is then transferred 
to the source computer, where the one or more key 
files are decrypted, and then encrypted utilizing the 
transfer key. The memory media is then carried to 
the target computer where the transfer key is gen- 
erated and utilized in a decryption operation to 
decrypt the one or more key files. Preferably, im- 
mediately the key files are encrypted utilizing an 
encryption operation which is keyed with a key 
which is uniquely associated with the target com- 
puter, and which may be derived from one or more 
unique computer configuration attributes. The first 
embodiment is discussed herein in connection with 
Figures 30, 31, 32, and 33. The second embodi- 
ment is discussed in connection with Figures 34 
and 35. 

Figures 30 and 31 depict in block diagram 
form export and import operations which allow an 
authorized user to move his permanent key to 
another data processing system using an "export" 
facility that produces a unique diskette image of 
the access key that has been enabled for import 
into another system. In accordance with the 
present invention, the access keys which are deliv- 
ered over the telephone by the software vendor to 
the customer are less than 40 bytes in length. The 
key file that is produced is over 2,000 bytes in 
length. An export facility is provided for copying 
the key file and the machine identification file to a 
diskette. Both files are then encrypted with a modi- 
fied diskette serial number to inhibit these files 
from being copied to a public forum where anyone 
could use them. An import facility provided in an- 
other system decrypts these files and adds the 
product key and machine identification from the 
diskette to a list of import product keys and ma- 
chine identifications in the import systems master 
file, and copies the key file to the import system 
hard disk. The key file is encrypted on the import 
system as is disclosed above. 

Figure 30 is a block diagram depiction of an 
export operation in accordance with the preferred 
embodiment of the present invention. As is shown, 



source computer 651 includes a key file 653 and a 
machine identification file 655. Key file 653 in- 
cludes the product key, the customer key, the clear 
text of the machine identification for source com- 
5 puter 653, trial interval data (such as a clock and/or 
counter which define the trial interval period), and 
an export counter which performs the dual func- 
tions of defining the maximum number of export 
operations allowed for the particular protected soft- 
10 ware products and keeping track of the total num- 
ber of export operations which have been accom- 
plished. The machine identification file includes the 
machine identification number and trial interval data 
(such as a clock and/or counter which defines the 
75 - trial interval period)r Both-key file- 653 and -machine - - 
identification file 655 are encrypted with any con- 
ventional encryption operation (such as the DES 
algorithm), which is keyed with a key which is 
derived from a unique system attribute of source 
20 computer 651. At the commencement of an export 
operation, key file 653 and machine identification 
file 655 are decrypted. Key file 653 is supplied as 
an input to decryption operation 657 which is 
keyed with key 659. Likewise, machine identifica- 
25 tion file 655 is supplied as an input to decryption 
operation 663 which is keyed with key 661. De- 
cryption operations 657, 663 generate a clear text 
version of key file 653 and machine identification 
file 655. Once the clear text is obtained, the export 
30 counter which is contained within key file 653 is 
modified in accordance with block 661. For exam- 
ple, if this is the seventh permitted export operation 
out' of ten permissible operations, the counter might 
read "7:10". The clear text version of key file 653 
35 is supplied as an input to encryption operation 669. 
Encryption operation 669 may be any conventional 
encryption operation (such as the DES algorithm), 
which is keyed with a memory media attribute 665 
which is unique to a memory media which is coup- 
40 led to source computer 651, which has been sub- 
jected to modification of modifier 667. For example, 
a unique diskette serial number may be supplied 
as the "memory media attribute" which is unique 
to memory media 677. The diskette serial number 
45 is modified in accordance with modifier 667 to alter 
it slightly, and supply it as an input to encryption 
operations 669. The same operation is performed 
for the clear text of machine identification file 655. 
A unique memory media attribute 671 is modified 
so by modifier 673 and utilized as a key for encryption 
operation 675, which may comprise any conven- 
tional encryption operation, such as the DES opera- 
tion. Finally, the output of encryption operations 
669 and 675 are supplied as inputs to copy oper- 
as ations 679, 681 which copy the encrypted key file 
653 and machine identification file 655 to memory 
media 677. 
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Figure 31 is a block diagram depiction of an 
import operation- Memory media 677 (of Figure 
30) is physically removed from source computer 
651 (of Figure 30) and physically carried over to 
computer 707 (of Figure 31); alternatively, in a 
distributed data processing system, this transfer 
may occur without the physical removal of memory 
media 677. With reference now to Figure 31, in 
accordance with block 683, the machine identifica- 
tion of the target machine is copied to memory 
media 677 to maintain a record of which particular 
target computer received the key file and machine 
identification file. Then, in accordance with blocks 
685, 693 the encrypted key file 653 and machine 
-identification- file-655- are-copied from- the-memory 
media to target computer 707. The encrypted key 
file 653 is supplied as an input to decryption opera- 
tion 689 which is keyed with key 687. Decryption 
operation 689 reverses the encryption operation of 
block 669, and provides as an output a clear text 
version of key file 653. Likewise, machine iden- 
tification file 655 is supplied as an input to decryp- 
tion operation 697, which is keyed with key 695. 
Decryption operation 697 reverses the encryption 
of encryption operation 675 and provides as an 
output the clear text of machine identification file 
655. In accordance with block 691, the machine 
identification of the source computer 651 is re- 
trieved and recorded in memory in the clear text of 
key file 653. Next, the clear text of key file 653 is 
supplied as an input to encryption operation 699. 
Encryption operation 699 is a conventional encryp- 
tion operation, such as the DES operation, which is 
keyed with a target computer unique attribute, such 
as the machine identification or modified machine 
identification for the target computer 707. The clear 
text of machine identification file 655 is supplied as 
an input to encryption operation 703. Encryption 
operation 703 is any conventional encryption op- 
eration, such as the DES encryption operation, 
which is keyed with a unique target computer at- 
tribute 705, such as machine identification or modi- 
fied machine identification of target computer 707. 
The output of encryption operation 699 produces 
an encrypted key file 709 which includes a product 
key (which is the same temporary product key of 
key file 653 of source computer 651), a customer 
number (which is the same customer number of 
key file 653 of source computer 651), and clear 
machine identification (which is the machine iden- 
tification for target computer 707, and not that of 
source computer 651), trial interval data (which is 
identical to the trail interval data of key file 653 of 
source 651), and an identification of the machine 
identification of the source computer 651 . The out- 
put of encryption operation 703 defines machine 
identification file 711, which includes the machine 
identification of the target computer 707 (and not 



that of the source computer 651), and the trial 
interval data (which is identical to that of machine 
identification file 655 of source computer 651). 

Figures 32 and 33 provide alternative views of 

5 the import and export operations which are de- 
picted in Figures 30 and 31, and emphasize sev- 
eral of the important features of the present inven- 
tion. As is shown, source computer 801 includes 
machine identification file 803 which is encrypted 

10 with a system attribute key which is unique to the 
source computer 801. The machine identification 
file includes machine identification file number as 
well as count of the number of exports allowed for 
each protected software product, and a count of 

75 - the -total number- of- exports- which have -been uti- 
lized. For example, the first export operation carries 
a count of "1:10", which signifies that one export 
operation of ten permitted export operations has 
occurred. In the next export operation, the counter 

20 is incremented to "2:20" which signifies that two of 
the total number of ten permitted export operations 
has occurred. Each target computer which receives 
the results of the export operation is tagged with 
this particular counter value, to identify that it is the 

25 recipient of a particular export operation. For exam- 
ple, one source computer system may carry a 
counter value of "1:10", which signifies that it is the 
recipient of the first export operation of ten permit- 
ted export operations. Yet another target computer 

30 may carry the counter value of "7:10", which sig- 
nifies that this particular target computer received 
the seventh export operation of a total of ten per- 
mitted export operations. In this fashion, the target 
computer maintains a count of a total number of 

35 used export operations, while the source comput- 
ers each carry a different counter value which 
identifies it a the recipient of the machine iden- 
tification file and key file from the source computer 
from particular ones of the plurality of permitted 

40 export operations. 

Note that in source computer 801 machine 
identification file 803 and key file 805 are encryp- 
ted with an encryption algorithm which utilizes as a 
key a system attribute which is unique to source 

45 computer 801; however, once machine identifica- 
tion file 803 and key file 805 are transferred to a 
memory media, such as export key diskette 807, 
machine identification file 809 and key file 81 1 are 
encrypted in any conventional encryption operation 

50 which utilizes as an encryption key a unique dis- 
kette attribute, such as the diskette's serial number. 
This minimizes the possibility that the content of 
the machine ID file 809 and/or key file 811 can be 
copied to another diskette or other memory media 

55 and then utilized to obtain unauthorized access to 
the software products. This is so because for an 
effective transfer of the content of machine ID file 
809 and key file 81 1 to a target computer to occur, 
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the target computer must be able to read and 
utilize the unique diskette attribute from the export 
key diskette 807. Only when the machine ID file 
809 and key file 811 are presented to a target 
computer on the diskette onto which these items 
were copied can an effective transfer occur. The 
presentation of the machine ID file 809 and key file 
811 on a diskette other than export key diskette 
807 to a potential target computer will result in the 
transfer of meaningless information, since the 
unique attribute of export key diskette 807 (such as 
the diskette serial number) is required by the target 
computer in order to successfully accomplish the 
decryption operation. 

As is shown in Figure 33, export key diskette 
807 is presented to target computer 813. Of 
course, the machine identification file 809 and key 
file 811 are in encrypted form. In the transfer from 
export key diskette 807 to target computer 813, the 
content of machine ID file 809 is updated with the 
machine identification of the target computer 813, 
and the count of imports utilized. In accomplishing 
the transfer to target computer 813, a machine 
identification file 815 is constructed which includes 
a number of items such as machine identification 
for the target computer 813, customer information, 
as well as a list of the machine identification num- 
ber of the source computer 801. Both machine 
identification file 815 and the key file 817 are 
encrypted utilizing a conventional encryption opera- 
tion which uses as a key a unique attribute of 
target computer 813. This ties machine identifica- 
tion file 815 and key file 817 to the particular target 
computer 813. 

By using an export/import counter to keep 
track of the total number of authorized ex- 
port/import operations, and the total number of 
used export/import operations, the present inven- 
tion creates an audit trail which can be utilized to 
keep track of the distribution of software products 
during the trial interval. Each source computer will 
carry a record of the total number of export oper- 
ations which have been performed. Each source 
computer will carry a record of which particular 
export/import operation was utilized to transfer one 
or more protected software products to the target 
computer. The memory media utilized to accom- 
plish the transfer (such as a diskette, or group of 
diskettes) will carry a permanent record of the 
machine identification numbers of both the source 
computer and the target computer's utilized in all 
export/import operations. 

The procedure for implementing export and 
import operations ensures that the protected soft- 
ware products are never exposed to unnecessary 
risks. When the machine identification file and key 
file are passed from the source computer to the 
export diskette, they are encrypted with the unique 



attribute of the export diskette which prevents or 
inhibits copying of the export diskette or posting of 
its contents to a bulletin board as a means for 
illegally distributing the keys. During the import 
5 operations, the machine identification and key files 
are encrypted with system attributes which are 
unique to the target computer to ensure that the 
software products are maintained in a manner 
which is consistent with the security of the source 
10 computer, except that those software products are 
encrypted with attributes which are unique to the 
target computer, thus preventing illegal copying 
and posting of the keys. 

The second embodiment of the export/import 
75 function is depicted in block diagram form in Fig- 
ures 34 and 35. In broad overview, memory media 
1677 is first utilized to interact with target computer 
1707 to obtain from target computer 1707 a trans- 
fer key which is unique to target computer 1707, 
20 and which is preferably derived from one or more 
unique system attributes of target computer 1707. 
The transfer key may be a modification of the 
machine identification for target computer 1707. 
Next, the memory media 1677 is utilized to interact 
25 with source computer 1651 in an export mode of 
operation, wherein key file 1653 and machine iden- 
tification file 1655 are first decrypted, and then 
encrypted utilizing the transfer key. 

Figure 34 is a block diagram depiction of an 
30 export operation in accordance with the preferred 
embodiment of the present invention. As is shown, 
source computer 1651 includes a key file 1653 and 
a machine identification file 1655. Key file 1653 
includes the product key, the customer key, the 
35 clear text of the machine identification for source 
computer 1653, trial interval data (such as a clock 
and/or counter which define the trial interval pe- 
riod), and an export counter which performs the 
dual functions of defining the maximum number of 
40 export operations allowed for the particular pro- 
tected software products and keeping track of the 
total number of export operations which have been 
accomplished. The machine identification file in- 
cludes the machine identification number and trial 
45 interval data (such as a clock and/or counter which 
defines the trial interval period). Both key file 1653 
and machine identification file 1655 are encrypted 
with any conventional encryption operation (such 
as the DES algorithm), which is keyed with a key 
so which is derived from a unique system attribute of 
source computer 1651. At the commencement of 
an export operation, key file 1653 and machine 
identification file 1655 are decrypted. Key file 1653 
is supplied as an input to decryption operation 
55 1657 which is keyed with key 1659. Likewise, ma- 
chine identification file 1655 is supplied as an input 
to decryption operation 1663 which is keyed with 
key 1661. Decryption operations 1657, 1663 gen- 
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erate a clear text version of key file 1653 and 
machine identification file 1655. Once the clear text 
is obtained, the export counter which is contained 
within key file 1653 is modified in accordance with 
block 1661. For example, if this is the seventh 
permitted export operation out of ten permissible 
operations, the counter might read "7:10". The 
clear text version of key file 1653 is supplied as an 
input to encryption operation 1669. Encryption op- 
eration 1669 may be any conventional encryption 
operation (such as the DES algorithm), which is 
keyed with the transfer key 1665 which was pre- 
viously obtained. The same operation is performed 
for the clear text of machine identification file 1655. 
Transfer key 1671 is utilized as a key for encryp- 
tion operation 1675, which may comprise any con- 
ventional encryption operation, such as the DES 
operation. Finally, the output of encryption oper- 
ations 1669 and 1675 are supplied as inputs to 
copy operations 1679, 1681 which copy the en- 
crypted key file 1653 and machine identification file 
1655 to memory media 1677. 

Figure 35 is a block diagram depiction of an 
import operation. Memory media 1677 (of Figure 
34) is physically removed from source computer 
1651 (of Figure 34) and physically carried over to 
computer 1707 (of Figure 35); alternatively, in a 
distributed data processing system, this transfer 
may occur without the physical removal of memory 
media 1677. With reference now to Figure 35, in 
accordance with block 1683, the machine iden- 
tification of the target machine is copied to memory 
media 1677 to maintain a record of which particular 
target computer received the key file and machine 
identification file. Then, in accordance with blocks 
1685, 1693 the encrypted key file 1653 and ma- 
chine identification file 1655 are copied from the 
memory media to target computer 1707. The en- 
crypted key file 1653 is supplied as an input to 
decryption operation 1689 which is keyed with key 
1687. Decryption operation 1689 reverses the en- 
cryption operation of block 1669, and provides as 
an output a clear text version of key file 1653. 
Likewise, machine identification file 1655 is sup- 
plied as an input to decryption operation 1697, 
which is keyed with key 1695. Decryption operation 
1697 reverses the encryption of encryption opera- 
tion 1675 and provides as an output the clear text 
of machine identification file 1655. In accordance 
with block 1691, the machine identification of the 
source computer 1651 is retrieved and recorded in 
memory in the clear text of key file 1653. Next, the 
clear text of key file 1653 is supplied as an input to 
encryption operation 1699. Encryption operation 
1699 is a conventional encryption operation, such 
as the DES operation, which is keyed with a target 
computer unique attribute, such as the machine 
identification or modified machine identification for 



the target computer 1707. The clear text of ma- 
chine identification file 1655 is supplied as an input 
to encryption operation 1703. Encryption operation 
1703 is any conventional encryption operation, 

5 such as the DES encryption operation, which is 
keyed with a unique target computer attribute 1705, 
such as machine identification or modified machine 
Identification of target computer 1707. The output 
of encryption operation 1699 produces an encryp- 

io ted key file 1709 which includes a product key 
(which is the same temporary product key of key 
file 1653 of source computer 1651), a customer 
number (which is the same customer number of 
key file 1653 of source computer 1651), and clear 

75 machine identification (which is the machine iden- 
tification for target computer 1707, and not that of 
source computer 1651), trial interval data (which is 
identical to the trail interval data of key file 1653 of 
source 1651), and an identification of the machine 

20 identification of the source computer 1651. The 
output of encryption operation 1703 defines ma- 
chine identification file 1711, which includes the 
machine identification of the target computer 1707 
(and not that of the source computer 1651), and 

25 the trial interval data (which is identical to that of 
machine identification file 1655 of source computer 
1651). 

While the invention has been particularly 
shown and described with reference to a preferred 
30 embodiment, it will be understood by those skilled 
in the art that various changes in form and detail 
may be made therein without departing from the 
spirit and scope of the invention. 

35 Claims 

1. A method of distributing a software object from 
a source to a user, comprising the method 
steps of: 

40 providing a software object; 

encrypting said software object with an encryp- 
tion operation utilizing a long-lived encryption 
key; 

directing said encrypted software object from 

45 said source to said user; 

loading said encrypted software object onto a 
user-controlled data processing system having 
a particular configuration; 
deriving a numerical machine identification 

50 based at least in part upon said particular 

configuration of said user-controlled data pro- 
cessing system; 

deriving a temporary key based at least in part 
upon said numerical machine identification and 
55 said long-lived encryption key; 

providing a long-lived key generator for receiv- 
ing said temporary key and producing said 
long-lived encryption key; and 
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allowing said user to utilize said temporary key 
for a prescribed interval to generate said long- 
lived encryption key to access said software 
object. 

2. A method of distributing a software object ac- 
cording to Claim 1, wherein said encrypted 
software object is recorded onto a computer- 
accessible memory media and directed from 
said source to said user. 

3. A method of distributing a software object ac- 
cording to Claim 1 or 2, wherein said long- 
lived key generator is recorded onto a com- 
puter-accessible memory media and directed 
from said source to said user along with said 
encrypted software object. 

4 A method of distributing a software object ac- 
cording to Claim one of claims 1 to 3, further 
comprising the method steps of: 
providing a file management program, which 
includes said long-lived key generator as a 
component thereof; and 

directing said file management program from 
said source to said user along with said en- 
crypted software object. 

5 A method of distributing a software object ac- 
cording to one of Claims 1 to 4, further com- 
prising the method steps of: 

creating a key file in said user-controlled data 
processing system for recording at least said 
temporary key. 

6 A method of distributing a software object ac- 
cording to Claim 5, further comprising the 
method steps of: 

encrypting said key file utilizing at least one 
unique system attribute as an encryption key. 

7. A method of distributing software objects from 
a producer to a user, comprising the method 
steps of: 

providing a software object; 
providing a computer-accessible memory me- 
dia; 

providing a file management program; 
encrypting said software object utilizing a long- 
lived key; 

recording said software object onto said com- 
puter-accessible memory media; 
shipping said computer-accessible memory 
from said producer to said user; 
loading said file management program into a 
user-controlled data processing system and 
associating it with an operating system for said 
user-controlled data processing system; 
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utilizing said file management program to de- 
rive a numerical machine identification based 
upon at least one attribute of said user-con- 
trolled data processing system; 
reading said computer-accessible memory with 
said user-controlled data processing system; 
deriving a temporary key based at least in part 
upon said numerical machine identification; 
utilizing said file management program by ex- 
ecuting it with said user-controlled data pro- 
cessing system to restrict access to said soft- 
ware object for an interval defined by said 
temporary key; and 

providing a long-lived key generator in said 
user-controlled data processing system which 
provides said long-lived key in response to 
receipt of at least said temporary key. 

A method of distributing software objects ac- 
cording to Claim 7, wherein said file manage- 
ment program is operable in a plurality of 
modes of operation when executed by said 
user-controlled data processing system, includ- 
ing the following modes of operation: 

(a) a temporary trial mode of operation, 
wherein said software object is temporarily 
enabled by utilizing said temporary key; 

(b) a permanent use mode of operation, 
wherein said software object is permanently 
enabled, allowing unlimited use of said soft- 
ware object by said user. 



45 



50 



55 



20 



BNSDOCID: <EP 0679980 A I. !..> 



EP 0 679 980 A1 




COMPUTER- 
ACCESSIBLE 
MEMORY 
MEDIA 




REMOVABLE KEY 



STAND ALONE PC 
FIG. 1 



BNSDOC1D: <EP.,._0679980Al_L> 



21 



EP 0 679 980 A1 




22 

BNSDOCID: <EP__ 0679980A1.J_> 



EP 0 679 980 A1 




BNSDOCID: <EP 067&980A1 I > 



23 



EP 0 679 980 A1 



201 

1 




SOFTWARE 




ENCRYPTION 


OBJECT 




ENGINE 



203 



285 



207 



ENCRYPTED 
SOFTWARE 
OBJECT 




VENDOR 
SOURCE 



FIG. 4 



MEMORY MEDIA 



213 



USER-SPECIFIC INFORMATION 



209 



i 



215 



MACHINE ID 



217 



PRODUCT KEY 
CUSTOMER NUMBER 



FIG. 5 




C USTOME R 
USER 



BNSDOCID: <EP_ 0679980A1_L> 



24 



EP 0 679 980 A1 



BEGIN 



219 



1 



221 



MAKE LANGUAGE/ 
LOCALE SELECTION 



i 



IDENTIFY TRY AND BUY 
OPTIONS BY COMPLETING 
APPROPRIATE FIELDS 



223 



I 



FUNCTIONALLY LIMIT 
• OR ENCRYPT 
TRY AND BUY PROGRAMS 



225 



LOAD SHELL- AND 
TRY AND BUY PROGRAMS ON 
COMPUTER-ACCESSIBLE 
MEMORY MEDIA 



227 



C^xT^>~ 229 

BUILDING THE SHELL 
FIG. 6 



BNSDOCID: -;EP O67S9a0A1..l_> 



25 



EP 0 679 980 A1 



23 1 




DISTRIBUTE COMPUTER- 
ACCESSIBLE MEDIA FOR 
TRY-AND-BUY 
TRIAL INTERVAL 



233 



I 



LOAD FILE MANAGEMENT 
PROGRAM FOR EXECUTION 



235 



I 



ALLOW BROWSING 
DISPLAY APPROPRIATE 
USER INTERFACE 



I 



237 



INTERACT WITH CUSTOMER 

TO GATHER INFO AND 
DISTRIBUTE TEMPORARY KEY 



239 



I 



ALLOW TRIAL FOR 
TRIAL INTERVAL 



241 



I 



MONITOR AND OVERSEE ALL 
I/O CALLS TO PREVENT- 
UNAUTHORIZED USE 



243 



I 



INTERACT WITH CUSTOMER 
TO DELIVER 
PERMANENT KEY 



245 




247 



CUSTOMER 
INTERACTION 

FIG. 7 



BNSDOCID: <EP 067&980A 1 . I. > 



26 



EP 0 679 980 A1 




BNSDOCID: <EP 0679980A1 ..!..> 



27 




BNSDOCID: <EP 067998OA1 J„> 



28 



EP 0 679 980 A1 




BNSDOCID: <EP 06799B0A1 J_> 



29 



EP 0 679 980 A1 



CD 




BNSDOCID. <EP„. 0679980A1J.. > 



30 



EP 0 679 980 A1 




BNSDOCID: <EP 0679980AK ' . > 



31 



EP 0 679 980 A1 



351 



USER'S 
COMPUTER 



^353 


355 
1 




USER- 




MACHINE ID 




SPECIFIC 




GENERATOR 




ATTRIBUTES 




(RANDOM) 




FIG. 12 



357 



MACHINE 




ID 





L 



359 



ENCRYPTION 
ENGINE 



I 



KEY 



I 



SYSTEM 
ATTRIBUTES 
SELECTION 



361 



ENCRYPTED 
MACHINE 
ID 



363 



365 



• 367 



1. HARD DISK SERIAL NO. 

2. SIZE OF HARD DISK 

3. FORMAT OF HARD DISK 

4. SYSTEM MODEL NO. 

5. HARDWARE INTERFACE CARD 

6. HARDWARE SERIAL NO. 

7 CONFIGURATION PARAMETERS 



FIG. 13 



BNSDOCID: <EP 0679960A 1 _!_> 



32 



EP 0 679 980 A1 



357. 



369 



371 



373 



374 



375 



MACHINE ID 



CUSTOMER NO. 



REAL KEY 



CONTROL BLOCK 



TRIAL 
INTERVAL DATA 




PRODUCT 
KEY 
ENCRYPTION 
ENGINE 



377 




GENERATION OF PRODUCT KEY 
FIG. H 



377 ^_ 

369 v 
373- 
357 • 
374 < 



PRODUCT KEY 



CUSTOMER NO. 



CONTROL BLOCK 



MACHINE ID 



TRIAL 
INTERVAL DATA 



379 
X 



REAL 
KEY 
GENERATOR 



381 



REAL 
KEY 
(DERIVED) 



VALIDATION OF PRODUCT KEY 
FIG. 15 



BNSDOCID: <EP._ 0S79980A1 J. > 



33 



1 1 



EP 0 679 980 A1 



383 



i 



CLEAR 
VALIDATION 
TEXT 
(DERIVED) 



393 




381 



385 



ENCRYPTED 




ENCRYPTION 


VALIDATION 




DATA 




ENGINE 


SEGMENT 




_ 






FIG. 16 


387 




389 



387 



CLEAR 
VALIDATION 
TEXT 
(DERIVED) 



1 



COMPARATOR 



E 



MATCH 


NO MATCH 




CREATE 
KEY 
FILE 


POST 
WARNING 



391 



CLEAR 
VALIDATION 
TEXT 
(KNOWN) 



395 



FIG. 17 



BNSDOCID: <EP 0679SB0A1..I > 



34 



EP 0 679 980 A1 



397 




KEY FILE 




- PRODUCT KEY 




- CUSTOMER KEY 




- CLEAR MACHINE 




ID 




- TRIAL INTERVAL 




DATA 





399 
1 



ENCRYPTION 
ENGINE 








KEY 






UNIQUE 
SYSTEM 
ATTRIBUTES 





485 

i_ 

ENCRYPTED 
KEY FILE 



401 



421 



FIG. 18 



^85 


ENCRYPTED 
FILE 




V 



READ 
HEADER 



FETCH 
KEY FILE 



489 



READ 
ENCRYPTED 
VALIDATION 

TEXT 



411 



FIG. 19 



06799eOA1 I > 



35 



EP 0 679 980 A1 



413 



DECRYPTION 




ENGINE 






421 



MACHINE ID 



415 



CUSTOMER KEY 



417 




419 



FIG. 20 



423 



1 



ENCRYPTED 
VALIDATION 
TEXT 



425 

I 


DECRYPTION 




ENGINE 





427 



CLEAR 
VALIDATION 
TEXT 
(DERIVED) 



REAL 
KEY 



421 



FIG. 21 



BNSDOCID: <EP 0679980A 1.J- * 



36 



EP 0 679 980 A1 



427 



1 



CLEAR 
VALIDATION 
TEXT 
(DERIVED) 



433 



429 



COMPARATOR 



I 



MATCH 




NO MATCH 




1 


DECRYPT 
SOFTWARE 
OBJECT 




POST 
WARNING 



431 



CLEAR 
VALIDATION 
TEXT 
(KNOWN) 



435 



FIG. 22 



437 



1 



ENCRYPTED 
SOFTWARE 
OBJECT 



439 



DECRYPTION 




ENGINE 




I 


i 


VALIDATED 




REAL 


KEY 





443 



SOFTWARE 
OBJECT 



441 



FIG. 23 



37 



EP 0 679 980 A1 



459 



453 



FILE DATA 



455 



457 



ENCRYPTION 
HEADER 



451 



UNIQUE 
IDENTIFIER 


NAME OF 
KEY FILE 


ENCRYPTED 
VALIDATION 
SEGMENT 


ENCRYPTION 
TYPE SEGMENT 


OFFSET TO 
SIDE FILE 


ENCRYPTED - 
FILE DATA 



461 



463 



ENCRYPTED FILE 
FIG. 24 



465 
467 

469 
471 
473 

475 



DIRECTORY OF 
ENCRYPTED FILES 



aaa 



SIDE FILE 



AAA 



bbb 
ccc 
ddd 



nnn 



BBB 

CCC 
DDD 



■ • • 



NNN 



- 477 

- 479 
<*481 

483 
-485 



FIG. 25 



BNSDOCID: <EP._.0879S60A1J_> 



38 



EP 0 679 980 A1 



LO 



CD 
LO 



in 



in 

LO 



CO 

in 



CO 
CO 



LU 

>- z 

LU 



LL<C 
i— 1 1 — 



LLI 



LU 

I 

» — i 

LL 

i 

LU 

Q 
y—t 

CO 



LU 



LU 

LLUJ 



ct: 

LU— 1 



LU 

m 
Z> 
I — 

<c 
o 

I— • 

CO 



CD 
O 



LU 
Q 
<C 
LU 
31 



O 



o 

LU 
X 
LU 
I 



CO 

LU 

— I 
• — • 

LL 

<: 
<*: 

Q 



LU 



~oa_ an— 

COILIIK 
(N00>0 




CN 

o 

I — I 

LL 



□s 






LE 




i — i 


LU 


" A 



a: 

LU 

a 

<: 

LU 



LO 
CN 
LO 



CD 
CO 



"ED 




ENCRYP1 
FILE 


1 






[LE 




LL ^ 


CLEAR 



CO 
CM 

in 



o 
o 



r: o 



CM 

in 



<c 
i — 

CO 
LU 



LL 



LL 
O LU 

UJ 



J 



BNSDOCID: <EP 0679980A 1 . \.> 



39 



EP 0 679 980 A1 




BNSOOCID: <EP 06799B0A1 J_> 



40 



EP 0 679 980 A1 



C 



BEGIN 



601 



I 



MONITOR I/O CALLS 



I 



FOR EACH I/O CALL. 
INTERCEPT CALLED FILE 



I 



DENY ACCESS TO 
OPERATING SYSTEM 



i 



READ PORTION OF FILE 
WHERE DECRYPTION 
BLOCK LOCATED 



I 



DERIVE KEY 
FILE ADDRESS 



i 



FETCH KEY FILE 



615 




NO 



603 



605 



607 



609 



611 



613 



617 




END 




TRIAL PERIOD 
OPERATION 

FIG. 29A 



BNSDOCID: <EP 0679980Al„l_> 



41 



EP 0 679 980 A1 




i 



L_ 



DERIVE KEY 



I 



DECRYPT 
VALUATION SEGMENT 



619 



621 



623 



DOES 
DECRYPTION 
VALUATION 
SEGMENT - 
CLEAR TEXT 



NO 



625 




END 



YES 



ALLOW ACCESS TO 
CALLED FILE 



i 



627 



READ DECRYPTION TYPE 



629 



I 



DECRYPT 



I 



^ 631 



PASS TO 
OPERATING SYSTEM 



633 




I 



END 




635 



TRIAL PERIOD 
OPERATION 

FIG. 29B 



BNSDOCID: <EP._.0679980A1_L> 



42 



EP 0 679 980 A1 




uj CO 

O 



O 

O- 
X 
UJ 



O 
i — i 

LL 









* 4 




LL 
i— i 




Q 




O 




21 




0679980A1 I 



43 



EP 0 679 980 A1 




BNSDOCID: <EP 0679S80A1 J_> 



44 



EP 0 679 980 A1 



C\l 
CO 




O 
Q_ 

LU 
O 

3 
O 
CO 



LU 

I 

i — i 

LL 

Q 
i — i 

LU 

l I 

X 

o 



LU 

\— 

I — CD 
i — 1 1 — i 

LU <c 

£u5 
I— 
oco>- 

zz. >- UJ 
LUCO^ 



UJ 
I— I 

o 

<: 

CO 



=>2 



llS 
o < 

°LL 

coo 

LU ^2 
q t— 

^LUCt 

-j 021 O 

m z HI 



LU 1 "; 

Pel 
Oh 



LU 
I 

I 1 

LL 



LU 



LU 

h- 
IEZ> 
I— CD 

» — i 

£u5 

I — 
O CO >- 
Z >- LU 
LUCO^ 



00 



CO 

oo 



in 

CO 



BNSDOCID: <EP _.. 06799eOA1 .1 > 



45 



EP 0 679 980 A1 




LU 



111 

cn 

i — i 

o 
>- 

UJ 



O 

X 
LU 



LU 



Q 

I — i 

LU 

\ — i 
X 

o 



LU 



-p(E) 
I — cd 

Q 

ULJUJ 
UJQV 



— , — llq 



LU 



LU^LO 



<C O -L- O 
3l_Z<kh 



LL 



LU 



-r CO 

o 

LULU 
Q-h- 

UJQ^ 



oo 



CO 
00 



00 



BNSDOCID- <EP__ 0679960A1_L> 



46 



EP 0 679 980 A1 




in 

CO 



UJ 




^2: 
22 






TRANSF 
KEY 




ENCRYPT 

operat: 


CO 


CO 

— • 






CD 






uj CO 
O _ 

h- o 
en 

x 

LU 











LU 


'AL 


TER 




>- 


UJ 


•— • 


^> 




LU 


UJ 




CH 


C£ 
ULI 


no 


I 




or 


<£ 


h- 




►—1 

UL 


}— 


UJ 


21 


i — * 


0 


2: 






1— 


>- 


Z) 


0 


ce: 




a: 


LU 


Q 


1 — 






0 




O 


CO 


LU 


1— 1 r— 


a_ 




a: 






a: << 


X 




a. 


O 


C_5 1 — 1 


1 — 0 


LU 




1 


1 


1 


1 


1 













< 


O 




> 






a: 




0 


NTE 


zn— • _i 


LU 


» — * 


MACI 
NTIF 
FI 


CHIN 




UJ 


<c 


a: -< 


0 




1 — a 


■ — t 


1 


1 



BNSDOCID: <EP 0679S80A1 .!..> 



47 



EP 0 679 980 A1 




CD 
CO 
CO 



tti 



00 
00 
CD 




Q 

5 QUJ o: 
I — 



CD 



CO 
CO 




on 
O 



LL 



BNSDOCID: <EP 0679980A1J_> 



48 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 95 10 5733 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



to < 



CLASSIFICATION OF THE 
APPLICATION (lnt-Ct.6) 



W0-A-94 072O4 (UNILOC) 

* abstract; figures 41,2,8 * 

* page 6, line 11 - page 9, line 5 * 

* page 10, line 3 - line 10 * 

* page 12, line 7 - page 17, line 13 * 

EP-A-0 268 139 (IBM) 

* column 1, line 1 - column 3, line 1 * 

* column 6, line 7 - column 7, line 50 * 

* column 9, line 20 - line 29 * 

* column 19, line 9 - line 50 * 

* column 21, 1 ine 6 - 1 ine 18 * 

* claims 2,9 * 

EP-A-0 561 685 (FUJITSU) 

* the whole document * 

IBM TECHNICAL DISCLOSURE BULLETIN, 
vol.33, no. 12, May 1991, NEW YORK, US; 
pages 70 - 71 

'Information Distribution via ROM Disks' 

* the whole document * 



1-8 



G06F1/00 
G06F12/14 



1-8 



1-8 



4,7 



TECHNICAL FIELDS 
SEARCHED (lnt.CJ.6) 



G06F 



The present search report has been drawn up for all claims 



8 

2 



Place ef t^mxh 

THE HAGUE 



Dtf • of coayletha of the Mark 

30 June 1995 



Powell, D 



2 

06 

o 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant if taken alone 

Y : particularly relevant if combined with another 

document of the same category 
A : technological background 
O : non-writtm disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on, or 

after the filing date 
D : document dted in the application 
L : document cited for other reasons 



A : member of the same patent family, corresponding 



BNSDOCID: <EP 0679980A1_L> 



This Page Blank (uspto) 



